feat: introduce ClickableRegion component to improve keyboard accessibility for interaction editors by Abhishek-Punhani · Pull Request #6094 · learningequality/studio

Abhishek-Punhani · 2026-08-17T17:06:16Z

Summary

Adding ClickableRegion component to improve keyboard accessibility for interaction editors

References

Reviewer guidance

Navigate to the Qti-demo-page and and test navigating Choice Editor prompt/choice cards using keyboard (Tab, Enter/Space) to verify accessible aria-label announcements, focus outlines, and seamless interaction with nested controls (TipTap, selection inputs, action buttons) without triggering parent clicks.

AI usage

Used Antigravity for final review and nitpicks.

Abhishek-Punhani · 2026-08-17T17:08:33Z

@AlexVelezLl, Should we add this to other interactions as well?

AlexVelezLl · 2026-08-17T17:12:13Z

Hi @Abhishek-Punhani! Yes, let's use this for the textEntry prompt, and I just merged the ordering interaction PR; we can refactor that editor as well!

AlexVelezLl

Thanks @Abhishek-Punhani! It's really nice these button are finally accessible! I've found couple of things we might be able to simplify on the code.

AlexVelezLl · 2026-08-19T09:16:53Z

+      class="overlay-button"
+      :aria-label="ariaLabel"
+      @keydown.enter.prevent="onClick"
+      @keydown.space.prevent="onClick"


If we add @click, we don't need to specify these two, as for button elements, the space and enter keystrokes also fire the onClick handler on a button element.

AlexVelezLl · 2026-08-19T09:44:47Z

                :minHeight="'80px'"
                :autofocus="mode === 'edit' && isQuestionOpen"
                :imageProcessor="EditorImageProcessor"
+                :tabindex="isQuestionOpen ? 0 : -1"


I don't think we need these tab indexes; if it's open, tabindex should also be -1 because we can already navigate through the editor to the input. (i.e., it should always be -1, as we are already handling the tab index in the outer container).

AlexVelezLl · 2026-08-19T09:48:19Z

      function handlePromptClick(event) {
        if (props.mode !== 'edit') return;
-        if (event.target.closest('button') || event.target.closest('input')) return;
+        const closestBtn =
+          event.target && event.target.closest ? event.target.closest('button') : null;
+        if (closestBtn && !closestBtn.classList.contains('overlay-button')) return;
+        const closestInput =
+          event.target && event.target.closest ? event.target.closest('input') : null;
+        if (closestInput) return;
        if (!isQuestionOpen.value) {
-          event.stopPropagation();
+          if (event && event.stopPropagation) event.stopPropagation();
          openQuestion();
        }
      }


Why do we need all of this? It's even less needed now because when the editor is already open, the Clickable region cannot fire any click event anymore, right?

AlexVelezLl · 2026-08-19T09:49:09Z

        return {
          borderColor: questionHasError.value ? tokens.error : tokens.fineLine,
-          cursor: props.mode === 'edit' ? 'pointer' : undefined,
+          '--clickable-region-hover-bg': palette.blue.v_100,


Hmm, I don't think we are using this anywhere.

AlexVelezLl · 2026-08-19T09:49:35Z

+        const closestBtn =
+          event.target && event.target.closest ? event.target.closest('button') : null;
+        if (closestBtn && !closestBtn.classList.contains('overlay-button')) return;
+        const closestInput =
+          event.target && event.target.closest ? event.target.closest('input') : null;
+        if (closestInput) return;
        if (!isPromptOpen.value) {
-          event.stopPropagation();
+          if (event && event.stopPropagation) event.stopPropagation();
          openPrompt();
        }
      }

      function handleItemClick(event, itemId) {
        if (props.mode !== 'edit') return;
        if (openItemId.value === itemId) return;
-        if (event.target.closest('button') || event.target.closest('input')) return;
-        event.stopPropagation();
+        const closestBtn =
+          event.target && event.target.closest ? event.target.closest('button') : null;
+        if (closestBtn && !closestBtn.classList.contains('overlay-button')) return;
+        const closestInput =
+          event.target && event.target.closest ? event.target.closest('input') : null;
+        if (closestInput) return;
+        if (event && event.stopPropagation) event.stopPropagation();


AlexVelezLl · 2026-08-19T09:49:46Z

      function handlePromptClick(event) {
        if (props.mode !== 'edit') return;
-        if (event.target.closest('button') || event.target.closest('input')) return;
+        const closestBtn =
+          event.target && event.target.closest ? event.target.closest('button') : null;
+        if (closestBtn && !closestBtn.classList.contains('overlay-button')) return;
+        const closestInput =
+          event.target && event.target.closest ? event.target.closest('input') : null;
+        if (closestInput) return;


Abhishek-Punhani · 2026-08-19T21:27:33Z

@AlexVelezLl , Thanks for pointing this out. I’ve removed the redundant @keydown handlers since @click.stop allows the button to handle Enter and Space activation natively.

I also tested moving @click="onClick" exclusively to the button, but that breaks mouse interactions because .content-wrapper sits above the button (z-index: 1). Removing the z-index would instead cause the button to capture clicks meant for nested interactive elements like radio buttons and checkboxes.

AlexVelezLl

Just a couple of things before merging!

AlexVelezLl · 2026-08-20T12:56:37Z

+
+  <div
+    class="clickable-area"
+    @click="onClick"


Just saw that this is similar to how we handle our KCard in KDS 😅, so yeah, that's fine. Could you add a comment here, please? We will introduce an a11y linter soon, and it will flag this as an incorrect pattern, but we should mute the linter instead, so it's best to add a clear comment explaining why a plain div has an @click handler without any tabindex/focus/space/enter management.

AlexVelezLl · 2026-08-20T12:59:44Z

+            event.target.closest(
+              'button:not(.overlay-button), input, a, select, textarea, [role="button"]',


Oh, I meant to ask about this earlier 😅. Why is this needed? Right now, all elements that sit on top of this region have a .stop modifier in their implementation, so we shouldn't need something like this. We can add a comment specifying that interactive elements on top of it should implement a .stop modifier. This would be the same pattern we use for KCard.

AlexVelezLl · 2026-08-20T13:07:33Z

+          clickable
+            ? instance.proxy.$computedClass({
+              ':hover': { backgroundColor: tokens.fineLine },
+            })


Could we use v-bind instead, similar to what you did for the TextEntry Editor? https://github.com/learningequality/studio/pull/6094/changes#diff-ce84be82b3009cec048a11c412c43d8ebe9a3055f682f745cb76d72afab21e80R462-R467

…bility for interaction editors Signed-off-by: Abhishek-Punhani <punhani.manavabhi@gmail.com>

AlexVelezLl

Thanks a lot @Abhishek-Punhani! LGTM!

Abhishek-Punhani force-pushed the click-region branch from ae28f15 to ba7e840 Compare August 17, 2026 17:34

AlexVelezLl requested changes Aug 19, 2026

View reviewed changes

Abhishek-Punhani force-pushed the click-region branch from ba7e840 to 5dc2938 Compare August 19, 2026 21:23

AlexVelezLl requested changes Aug 20, 2026

View reviewed changes

feat: introduce ClickableRegion component to improve keyboard accessi…

1c96b33

…bility for interaction editors Signed-off-by: Abhishek-Punhani <punhani.manavabhi@gmail.com>

Abhishek-Punhani force-pushed the click-region branch from 5dc2938 to 1c96b33 Compare August 20, 2026 20:35

Abhishek-Punhani requested a review from AlexVelezLl August 21, 2026 10:46

AlexVelezLl approved these changes Aug 21, 2026

View reviewed changes

AlexVelezLl merged commit 52835d3 into learningequality:unstable Aug 21, 2026
20 checks passed

		event.target.closest(
		'button:not(.overlay-button), input, a, select, textarea, [role="button"]',

Uh oh!

Uh oh!

Conversation

Abhishek-Punhani commented Aug 17, 2026 • edited by AlexVelezLl Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

References

Reviewer guidance

AI usage

Uh oh!

Abhishek-Punhani commented Aug 17, 2026

Uh oh!

AlexVelezLl commented Aug 17, 2026

Uh oh!

AlexVelezLl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abhishek-Punhani commented Aug 19, 2026

Uh oh!

AlexVelezLl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlexVelezLl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Abhishek-Punhani commented Aug 17, 2026 •

edited by AlexVelezLl

Loading